If set to "@saved" the chosen entry will be saved as an EFI variable on every boot and automatically selected the next time the boot loader starts.

Table 1. Automatically detected entries will use the following names:

Supported glob wildcard patterns are
"?", "*", and "[...]" (including ranges). Note that these patterns use the same syntax as glob(7), but do not support all features. In particular, set negation and named character classes are not supported. The matching is done case-insensitively on the entry ID (as shown by bootctl list).

If set to "menu-hidden" or "0" (the default) no menu is shown and the default entry will be booted immediately. The menu can be shown by pressing and holding a key before systemd-boot is launched. Setting this to "menu-force" disables the timeout while always showing the menu.

0

1

2

auto

max

keep

Takes one of "off", "manual" or "force". Controls the enrollment of secure boot keys. If set to "off", no action whatsoever is taken. If set to "manual" (the default) and the UEFI firmware is in setup-mode then entries to manually enroll Secure Boot variables are created in the boot menu. If set to "force", in addition, if a directory named /loader/keys/auto/ exists on the ESP then the keys in that directory are enrolled automatically.

The different sets of variables can be set up under /loader/keys/NAME where NAME is the name that is going to be used as the name of the entry. This allows one to ship multiple sets of Secure Boot variables and choose which one to enroll at runtime.

Supported secure boot variables are one database for authorized images, one key exchange key (KEK) and one platform key (PK). For more information, refer to the UEFI specification[2], under Secure Boot and Driver Signing. Another resource that describe the interplay of the different variables is the EDK2 documentation[3].

A complete set of UEFI variable includes db.auth, KEK.auth and PK.auth. Note that these files need to be authenticated UEFI variables. See below for an example of how to generate them from regular X.509 keys.

uuid=$(systemd-id128 new --uuid)
for key in PK KEK db; do


  openssl req -new -x509 -subj "/CN=${key}/" -keyout "${key}.key" -out "${key}.crt"


  openssl x509 -outform DER -in "${key}.crt" -out "${key}.cer"


  cert-to-efi-sig-list -g "${uuid}" "${key}.crt" "${key}.esl"
done
for key in MicWinProPCA2011_2011-10-19.crt MicCorUEFCA2011_2011-06-27.crt MicCorKEKCA2011_2011-06-24.crt; do


  curl "https://www.microsoft.com/pkiops/certs/${key}" --output "${key}"


  sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output "${key%crt}esl" "${key}"
done
# Optionally add Microsoft Windows Production CA 2011 (needed to boot into Windows).
cat MicWinProPCA2011_2011-10-19.esl >> db.esl
# Optionally add Microsoft Corporation UEFI CA 2011 (for firmware drivers / option ROMs
# and third-party boot loaders (including shim). This is highly recommended on real
# hardware as not including this may soft-brick your device (see next paragraph).
cat MicCorUEFCA2011_2011-06-27.esl >> db.esl
# Optionally add Microsoft Corporation KEK CA 2011. Recommended if either of the
# Microsoft keys is used as the official UEFI revocation database is signed with this
# key. The revocation database can be updated with fwupdmgr(1).
cat MicCorKEKCA2011_2011-06-24.esl >> KEK.esl
sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl PK.auth
sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl KEK.auth
sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth


        

This feature is considered dangerous because even if all the required files are signed with the keys being loaded, some files necessary for the system to function properly still won't be. This is especially the case with Option ROMs (e.g. for storage controllers or graphics cards). See Secure Boot and Option ROMs[4] for more details.

Work around BitLocker requiring a recovery key when the boot loader was updated (disabled by default).

Try to detect BitLocker encrypted drives along with an active TPM. If both are found and Windows Boot Manager is selected in the boot menu, set the "BootNext" EFI variable and restart the system. The firmware will then start Windows Boot Manager directly, leaving the TPM PCRs in expected states so that Windows can unseal the encryption key. This allows systemd-boot to be updated without having to provide the recovery key for BitLocker drive unlocking.

Note that the PCRs that Windows uses can be configured with the "Configure TPM platform validation profile for native UEFI firmware configurations" group policy under "Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption". When secure boot is enabled, changing this to PCRs "0,2,7,11" should be safe. The TPM key protector needs to be removed and then added back for the PCRs on an already encrypted drive to change. If PCR 4 is not measured, this setting can be disabled to speed up booting into Windows.

# /boot/efi/loader/loader.conf
timeout 0
default 01234567890abcdef1234567890abdf0-*
editor no